Data exchange-based platform

ABSTRACT

A method includes receiving, from a client device, a request to access data of a data exchange platform. The method further includes receiving a selection corresponding to a monetization option for the data. The method further includes executing, by one or more processors, a monetization operation corresponding to the selection without directing the client device outside of the data exchange platform. The method further includes granting the client device access to the data of the data exchange platform in response to successfully performing the monetization operation.

CROSS REFERENCE TO RELATED APPLICATIONS

The present application claims the benefit of U.S. ProvisionalApplication No. 62/961,064, filed Jan. 14, 2020, the full contents ofwhich are incorporated herein by reference.

TECHNICAL FIELD

The present disclosure relates to resource management systems andmethods that manage data storage and computing resources.

BACKGROUND

Databases are widely used for data storage and access in computingapplications. Databases may include one or more tables that include orreference data that can be read, modified, or deleted using queries.Databases may be used for storing and/or accessing personal informationor other sensitive information. Secure storage and access of databasedata may be provided by encrypting and/or storing data in an encryptedform to prevent unauthorized access. In some cases, data sharing may bedesirable to let other parties perform queries against a set of data.

BRIEF DESCRIPTION OF THE DRAWINGS

The described embodiments and the advantages thereof may best beunderstood by reference to the following description taken inconjunction with the accompanying drawings. These drawings in no waylimit any changes in form and detail that may be made to the describedembodiments by one skilled in the art without departing from the spiritand scope of the described embodiments.

FIG. 1A is a block diagram depicting an example computing environment inwhich the methods disclosed herein may be implemented.

FIG. 1B is a block diagram illustrating an example virtual warehouse.

FIG. 2 is a schematic block diagram of data that may be used toimplement a public or private data exchange in accordance with anembodiment of the present invention.

FIG. 3 is a schematic block diagram of components for implementing adata exchange in accordance with an embodiment of the present invention.

FIG. 4A is a process flow diagram of a method for controlled sharing ofdata among entities in a data exchange in accordance with an embodimentof the present invention.

FIG. 4B is a diagram illustrating data used for implementing privatesharing of data in accordance with an embodiment of the presentinvention.

FIG. 4C is a diagram illustrating a secure view for implementing privatesharing of data in accordance with an embodiment of the presentinvention.

FIG. 5 is a process flow diagram of a method for public sharing of dataamong entities in a data exchange in accordance with an embodiment ofthe present invention.

FIG. 6 is a process flow diagram of a method for performingbi-directional shares in a data exchange in accordance with anembodiment of the present invention.

FIG. 7 is a process flow diagram of a method for providing enriched datain a data exchange in accordance with an embodiment of the presentinvention.

FIG. 8 is a block diagram illustrating a network environment in which adata provider may share data via a cloud computing service.

FIG. 9 is an example private data exchange in accordance with anembodiment of the present invention.

FIG. 10 is a diagram illustrating an example secure view of shared datafrom a private data exchange.

FIG. 11 is a diagram illustrating an example tunneling of a data listingbetween two private data exchanges.

FIG. 12 is a diagram illustrating an example data query and deliveryservice according to some embodiments of the invention.

FIG. 13 is a flow diagram illustrating a method of data exchange-basedmonetization according to some embodiments of the invention.

FIG. 14 is a block diagram of an example computing device that mayperform one or more of the operations described herein, in accordancewith some embodiments.

DETAILED DESCRIPTION

Data providers often own data assets that may be cumbersome to share andmonetize. Various embodiments describe methods by which data owners maybe compensated for sharing data outside of a data exchange. Such methodsarea not without drawbacks. Specifically, requiring data providers andconsumers to go outside a data exchange for payment may be cumbersome,insecure, and inefficient. Such methods may be at risk of inaccuracy andmay be bogged down by unnecessary steps.

By contrast, the embodiments described herein provide for cross-clouddata discovery, data delivery, and payment for data that can be handledseamlessly in a coordinated and friction-free manner. As soon as a paiddata offering is selected, billing, filtration, and delivery of shareddata can begin immediately. Correspondingly, if payment stops or fails,access to data can be cut off immediately. Also this approachpotentially allows for usage-based data pricing models, which may bebetter than simpler subscription models in some cases. Furthermore, theembodiments described herein provide for more efficient and faster dataexchange computer systems, at least because all required operations fordata discovery, delivery, and payment may be handled by the same one ormore computer systems, optimized to perform such tasks in concert. Oneadvantage the current embodiments utilize to enable a variety ofmonetization options is due to the fact that access to particular datamay be restricted based on a monetization action or non-action (e.g.,failure to pay), since a copy of the data itself is not copied outsideof the data owner's account in the data exchange platform. As such, datasecurity may be increased due to an ability to efficiently restrictaccess to the data. Furthermore, while embodiments herein are describedwith respect the SQL and SQL-based queries and database structures, anyother suitable database protocols and structures may be used.

The embodiments described herein provide various techniques for dataowners to be compensated for access to data that they offer via publicand/or private data exchanges. In one embodiment, a private dataexchange may allow data providers to more easily and securely sharetheir data assets with other entities. A private data exchange can beunder the data provider's brand, and the data provider may control whocan gain access to it. The private data exchange may be for internal useonly, or may also be opened to select customers, partners, suppliers, orothers. The data provider may control what data assets are listed aswell as control who has access to which sets of data. This allows for aseamless way to discover and share data both within a data provider'sorganization and with its business partners.

The private data exchange may be facilitated by a cloud computingservice such as SNOWFLAKE, and allows data providers to offer dataassets directly from a data warehouse in a private online marketplacewith their own branding. The private data exchange may provide acentralized, managed hub for an entity to list internally orexternally-shared data assets, inspire data collaboration, and also tomaintain data governance and to audit access. With the private dataexchange, data providers may be able to share data without copying itbetween companies. Data providers may invite other entities to viewtheir data listings, control which data listings appear in their privateonline marketplace, control who can access data listings and how otherscan interact with the data assets connected to the listings. This may bethought of as a “walled garden” marketplace, in which visitors to thegarden must be approved and access to certain listings may be limited.

As an example, Company A may be a consumer data company that hascollected and analyzed the consumption habits of millions of individualsin several different categories. Their data sets may include data in thefollowing categories: online shopping, video streaming, electricityconsumption, automobile usage, internet usage, clothing purchases,mobile application purchases, club memberships, and online subscriptionservices. Company A may desire to offer these data sets (or subsets orderived products of these data sets) to other entities. For example, anew clothing brand may wish to access data sets related to consumerclothing purchases and online shopping habits. Company A may support apage on its website, within the SNOWFLAKE or similar system, or througha similar component that is a private data exchange, where a dataconsumer (e.g., the new clothing brand) may browse, explore, discover,access and potentially purchase data sets directly from Company A.Further, Company A may control: who can enter the private data exchange,the entities that may view a particular listing, the actions that anentity may take with respect to a listing (e.g., view only), whetherrequests to access data are granted immediately or only after data ownerapproval, and any other suitable action. In addition, a data providermay combine its own data with other data sets from, e.g., a public dataexchange, and create new listings using the combined data.

A private data exchange may be an appropriate place to discover,assemble, clean, and enrich data to make it more useful or monetizable,as described herein. A large company on a private data exchange mayassemble data from across its divisions and departments, which couldbecome valuable to another company. In addition, participants in aprivate ecosystem data exchange may work together to join their datasetstogether to jointly create a useful data product that any one of themalone would not be able to produce. Once these joined datasets arecreated, they may be listed on a public or private data exchange.

The systems and methods described herein provide a flexible and scalabledata warehouse monetization techniques using a data processing platform.In some embodiments, the described systems and methods leverage a cloudinfrastructure that supports cloud-based storage resources, computingresources, and the like. Example cloud-based storage resources offersignificant storage capacity available on-demand at a low cost. Further,these cloud-based storage resources may be fault-tolerant and highlyscalable, which can be costly to achieve in private data storagesystems. Example cloud-based computing resources are available on-demandand may be priced based on actual usage levels of the resources.Typically, the cloud infrastructure is dynamically deployed,reconfigured, and decommissioned in a rapid manner.

In the described systems and methods, a data storage system utilizes anSQL (Structured Query Language)-based relational database. However,these systems and methods are applicable to any type of database, andany type of data storage and retrieval platform, using any data storagearchitecture and using any language to store and retrieve data withinthe data storage and retrieval platform. The systems and methodsdescribed herein further provide a multi-tenant system that supportsisolation of computing resources and data between differentcustomers/clients and between different users within the samecustomer/client.

FIG. 1A is a block diagram of an example computing environment 100 inwhich the systems and methods disclosed herein may be implemented. Inparticular, a cloud computing platform 110 may be implemented, such asAMAZON WEB SERVICES™ (AWS), MICROSOFT AZURE™, GOOGLE CLOUD™, or thelike. As known in the art, a cloud computing platform 110 providescomputing resources and storage resources that may be acquired(purchased) or leased and configured to execute applications and storedata.

The cloud computing platform 110 may host a cloud computing service 112that facilitates storage of data on the cloud computing platform 110(e.g. data management and access) and analysis functions (e.g. SQLqueries, analysis), as well as other computation capabilities (e.g.,secure data sharing between users of the cloud computing platform 110).The cloud computing platform 110 may include a three-tier architecture:data storage 140, query processing 130, and cloud services 120.

Data storage 140 may facilitate the storing of data on the cloudcomputing platform 110 in one or more cloud databases 141. Data storage140 may use a storage service such as AMAZON S3 to store data andretrieve data on the cloud computing platform 110. In particularembodiments, to load data into the cloud computing platform 110, datatables may be horizontally partitioned into small, immutable files whichmay be analogous to blocks or pages in a traditional database system.Within each file, the values of each attribute or column are groupedtogether and compressed using a scheme sometimes referred to as hybridcolumnar. Each table has a header which, among other metadata, containsthe offsets of each column within the file.

In addition to storing table data, data storage 140 facilitates thestorage of temp data generated by query operations (e.g., joins), aswell as the data contained in large query results. This may allow thesystem to compute large queries without out-of-memory or out-of-diskerrors. Storing query results this way may simplify query processing asit removes the need for server-side cursors found in traditionaldatabase systems.

Query processing 130 may handle query execution within elastic clustersof virtual machines, referred to herein as virtual warehouses or datawarehouses. Thus, query processing 130 may include one or more virtualwarehouses 131, which may also be referred to herein as data warehouses.The virtual warehouses 131 may be one or more virtual machines operatingon the cloud computing platform 110. The virtual warehouses 131 may becompute resources that may be created, destroyed, suspended, resumed, orresized at any point, on demand. This functionality may create an“elastic” virtual warehouse that expands, contracts, or shuts downaccording to the user's needs. Expanding a virtual warehouse involvesadding one or more compute nodes 132 to a virtual warehouse 131.Contracting a virtual warehouse involves removing one or more computenodes 132 from a virtual warehouse 131. More compute nodes 132 may leadto faster compute times. For example, a data load which takes fifteenhours on a system with four nodes might take less than two hours withthirty-two nodes.

Cloud services 120 may be a collection of services that coordinateactivities across the cloud computing service 110. These services tietogether all of the different components of the cloud computing service110 in order to process user requests, from login to query dispatch.Cloud services 120 may operate on compute instances provisioned by thecloud computing service 110 from the cloud computing platform 110. Cloudservices 120 may include a collection of services that manage virtualwarehouses, queries, transactions, data exchanges, and the metadataassociated with such services, such as database schemas, access controlinformation, encryption keys, and usage statistics. Cloud services 120may include, but not be limited to, authentication engine 121,infrastructure manager 122, optimizer 123, exchange manager 124,security 125 engine, and metadata storage 126.

FIG. 1B is a block diagram illustrating an example virtual warehouse131. The exchange manager 124 may facilitate the sharing of data betweendata providers and data consumers, using, for example, a private dataexchange. For example, cloud computing service 112 may manage thestorage and access of a database 108. The database 108 may includevarious instances of user data 150 for different users, e.g. differententerprises or individuals. The user data may include a user database152 of data stored and accessed by that user. The user database 152 maybe subject to access controls such that only the owner of the data isallowed to change and access the database 112 upon authenticating withthe cloud computing service 112. For example, data may be encrypted suchthat it can only be decrypted using decryption information possessed bythe owner of the data. Using the exchange manager 124, specific datafrom a user database 152 that is subject to these access controls may beshared with other users in a controlled manner according to the methodsdisclosed herein. In particular, a user may specify shares 154 that maybe shared in a public or private data exchange in an unconstrainedmanner or shared with specific or approved other users in a controlledmanner as described above. A “share” encapsulates all of the informationrequired to share data in a database. A share may include a variety ofinformation, for example: (1) privileges that grant access to thedatabase(s) and the schema containing the objects to share, (2) theprivileges that grant access to the specific objects (e.g., tables,secure views, and secure UDFs), and optionally (3) the consumer accountswith which the database and its objects are shared. When data is shared,no data is copied or transferred between user accounts. Sharing iscontrolled through the cloud services 120 of cloud computing service110.

Sharing data may be performed when a data provider creates a share of adatabase in the data provider's account and grants access to particularobjects (e.g., tables, secure views, and secure user-defined functions(UDFs)). Then a read-only database may be created using informationprovided in the share. Access to this database may be controlled by thedata provider.

Shared data may then be used to process SQL queries, possibly includingjoins, aggregations, or other analysis. In some instances, a dataprovider may define a share such that “secure joins” are permitted to beperformed with respect to the shared data. A secure join may beperformed such that analysis may be performed with respect to shareddata but the actual shared data is not accessible by the data consumer(e.g., recipient of the share). A secure join may be performed asdescribed in U.S. application Ser. No. 16/368,339, filed Mar. 18, 2019,and entitled SECURE DATA JOINS IN A MULTIPLE TENANT DATABASE SYSTEM.

User devices 101-104, such as laptop computers, desktop computers,mobile phones, tablet computers, cloud-hosted computers, cloud-hostedserver-less processes, or other computing processes or devices may beused to access the virtual warehouse 131 or cloud service 120 by way ofa network 105, such as the Internet or a private network.

In the description below, actions are ascribed to users, particularlyconsumers and providers. Such actions shall be understood to beperformed with respect to devices 101-104 operated by such users. Forexample, notification to a user may be understood to be a notificationtransmitted to devices 101-104, an input or instruction from a user maybe understood to be received by way of the user's devices 101-104, andinteraction with an interface by a user shall be understood to beinteraction with the interface on the user's devices 101-104. Inaddition, database operations (joining, aggregating, analysis, etc.)ascribed to a user (consumer or provider) shall be understood to includeperforming of such actions by the cloud computing service 110 inresponse to an instruction from that user.

FIG. 2 is a schematic block diagram of data that may be used toimplement a public or private data exchange in accordance with anembodiment of the present invention. The exchange manager 124 mayoperate with respect to some or all of the illustrated exchange data200, which may be stored on the platform executing the exchange manager124 (e.g., the cloud computing platform 110) or at some other location.The exchange data 200 may include a plurality of listings 202 describingdata that is shared by a first user (“the provider”). The listings 202may be listings in a private data exchange or in a public data exchange.The access controls, management, and governance of the listings may besimilar for both a public data exchange and a private data exchange.

A listing 202 may include metadata 204 describing the shared data. Themetadata 204 may include some or all of the following information: anidentifier of the sharer of the shared data, a URL associated with thesharer, a name of the share, a name of tables, a category to which theshared data belongs, an update frequency of the shared data, a catalogof the tables, a number of columns and a number of rows in each table,as well as name for the columns. The metadata 204 may also includeexamples to aid a user in using the data. Such examples may includesample tables that include a sample of rows and columns of an exampletable, example queries that may be run against the tables, example viewsof an example table, example visualizations (e.g., graphs, dashboards)based on a table's data. Other information included in the metadata 204may be metadata for use by business intelligence tools, text descriptionof data contained in the table, keywords associated with the table tofacilitate searching, a link (e.g., URL) to documentation related to theshared data, and a refresh interval indicating how frequently the shareddata is updated along with the date the data was last updated.

The listing 202 may include access controls 206, which may beconfigurable to any suitable access configuration. For example, accesscontrols 206 may indicate that the shared data is available to anymember of the private exchange without restriction. The access controls206 may specify a class of users (members of a particular group ororganization) that are allowed to access the data and/or see thelisting. The access controls 206 may specify that a “point-to-point”share (see discussion of FIG. 4) in which users may request access butare only allowed access upon approval of the provider. The accesscontrols 206 may specify a set of user identifiers of users that areexcluded from being able to access the data referenced by the listing202.

Note that some listings 202 may be discoverable by users without furtherauthentication or access permissions whereas actual accesses are onlypermitted after a subsequent authentication step (see discussion ofFIGS. 4 and 6). The access controls 206 may specify that a listing 202is only discoverable by specific users or classes of users.

Note also that a default function for listings 202 is that the datareferenced by the share is exportable by the consumer. Alternatively,the access controls 206 may specify that this is not permitted. Forexample, access controls 206 may specify that secure operations (securejoins and secure functions as discussed below) may be performed withrespect to the shared data such that viewing and exporting of the shareddata is not permitted.

In some embodiments, once a user is authenticated with respect to alisting 202, a reference to that user (e.g., user identifier of theuser's account with the virtual warehouse 131) is added to the accesscontrols 206 such that the user will subsequently be able to access thedata referenced by the listing 202 without further authentication.

The listing 202 may define one or more filters 208. For example, thefilters 208 may define specific user identifiers 214 of users that mayview references to the listing 202 when browsing the catalog 220. Thefilters 208 may define a class of users (users of a certain profession,users associated with a particular company or organization, users withina particular geographical area or country) that may view references tothe listing 202 when browsing the catalog 220. In this manner, a privateexchange may be implemented by the exchange manager 124 using the samecomponents. In some embodiments, an excluded user that is excluded fromaccessing a listing 202, i.e. adding the listing 202 to the consumedshares 156 of the excluded user, may still be permitted to view arepresentation of the listing when browsing the catalog 220 and mayfurther be permitted to request access to the listing 202 as discussedbelow. Requests to access a listing by such excluded users and otherusers may be listed in an interface presented to the provider of thelisting 202. The provider of the listing 202 may then view demand foraccess to the listing and choose to expand the filters 208 to permitaccess to excluded users or classes of excluded users (e.g., users inexcluded geographic regions or countries).

Filters 208 may further define what data may be viewed by a user. Inparticular, filters 208 may indicate that a user that selects a listing202 to add to the consumed shares 156 of the user is permitted to accessthe data referenced by the listing but only a filtered version that onlyincludes data associated with the identifier 214 of that user,associated with that user's organization, or specific to some otherclassification of the user. In some embodiments, a private exchange isby invitation: users invited by a provider to view listings 202 of aprivate exchange are enabled to do by the exchange manager 124 uponcommunicating acceptance of an invitation received from the provider.

In some embodiments, a listing 202 may be addressed to a single user.Accordingly, a reference to the listing 202 may be added to a set of“pending shares” that is viewable by the user. The listing 202 may thenbe added to a group of shares of the user upon the user communicatingapproval to the exchange manager 124.

The listing 202 may further include usage data 210. For example, thecloud computing service 112 may implement a credit system in whichcredits are purchased by a user and are consumed each time a user runs aquery, stores data, or uses other services implemented by the cloudcomputing service 112. Accordingly, usage data 210 may record an amountof credits consumed by accessing the shared data. Usage data 210 mayinclude other data such as a number of queries, a number of aggregationsof each type of a plurality of types performed against the shared data,or other usage statistics. In some embodiments, usage data for a listing202 or multiple listings 202 of a user is provided to the user in theform of a shared database, i.e. a reference to a database including theusage data is added by the exchange manager 124 to the consumed sharesof the user.

The listing 202 may also include a heat map 211, which may represent thegeographical locations in which users have clicked on that particularlisting. The cloud computing service 110 may use the heat map to makereplication decisions or other decisions with the listing. For example,a private data exchange may display a listing that contains weather datafor Georgia, USA. The heat map 211 may indicate that many users inCalifornia are selecting the listing to learn more about the weather inGeorgia. In view of this information, the cloud computing service 110may replicate the listing and make it available in a database whoseservers are physically located in the western United States, so thatconsumers in California may have access to the data. In someembodiments, an entity may store its data on servers located in thewestern United States. A particular listing may be very popular toconsumers. The cloud computing service 110 may replicate that data andstore it in servers located in the eastern United States, so thatconsumers in the Midwest and on the East Coast may also have access tothat data.

The listing 202 may also include one or more tags 213. The tags 213 mayfacilitate simpler sharing of data contained in one or more listings. Asan example, a large company may have a human resources (HR) listingcontaining HR data for its internal employees on a private dataexchange. The HR data may contain ten types of HR data (e.g., employeenumber, selected health insurance, current retirement plan, job title,etc.). The HR listing may be accessible to 100 people in the company(e.g., everyone in the HR department). Management of the HR departmentmay wish to add an eleventh type of HR data (e.g., an employee stockoption plan). Instead of manually adding this to the HR listing andgranting each of the 100 people access to this new data, management maysimply apply an HR tag to the new data set and that can be used tocategorize the data as HR data, list it along with the HR listing, andgrant access to the 100 people to view the new data set.

The listing 202 may also include version metadata 215. Version metadata215 may provide a way to track how the datasets are changed. This mayassist in ensuring that the structure and schema of data that is beingviewed by one entity is not changed prematurely. For example, if acompany has an original data set and then releases an updated version ofthat data set, the updates could interfere with another user'sprocessing of that data set, because the update could have differentformatting, new columns, and other changes that may be incompatible withthe current processing mechanism of the recipient user. To remedy this,the cloud computing service 112 may track version updates using versionmetadata 215. The cloud computing service 112 may ensure that each dataconsumer accesses the same version of the data until they accept anupdated version that will not interfere with current processing of thedata set.

The exchange data 200 may further include user records 212. The userrecord 212 may include data identifying the user associated with theuser record 212, e.g. an identifier (e.g., warehouse identifier) of auser having user data 150 in service database 128 and managed by thevirtual warehouse 131.

The user record 212 may list shares associated with the user, e.g.,reference listings 202 created by the user. The user record 212 may listshares consumed by the user, e.g. reference listings 202 created byanother user and that have been associated to the account of the useraccording to the methods described herein. For example, a listing 202may have an identifier that will be used to reference it in the sharesor consumed shares of a user record 212.

The exchange data 200 may further include a catalog 220. The catalog 220may include a listing of all available listings 202 and may include anindex of data from the metadata 204 to facilitate browsing and searchingaccording to the methods described herein. In some embodiments, listings202 are stored in the catalog in the form of JavaScript Object Notation(JSON) objects.

Note that where there a multiple instances of the virtual warehouse 131on different cloud computing platforms, the catalog 220 of one instanceof the virtual warehouse 131 may store listings or references tolistings from other instances on one or more other cloud computingplatforms 110. Accordingly, each listing 202 may be globally unique(e.g., be assigned a globally unique identifier across all of theinstances of the virtual warehouse 131). For example, the instances ofthe virtual warehouses 131 may synchronize their copies of the catalog220 such that each copy indicates the listings 202 available from allinstances of the virtual warehouse 131. In some instances, a provider ofa listing 202 may specify that it is to be available on only onspecified on or more computing platforms 110.

In some embodiments, the catalog 220 is made available on the Internetsuch that it is searchable by a search engine such as BING or GOOGLE.The catalog may be subject to a search engine optimization (SEO)algorithm to promote its visibility. Potential consumers may thereforebrowse the catalog 220 from any web browser. The exchange manager 124may expose uniform resource locators (URLs) linked to each listing 202.This URL may be searchable can be shared outside of any interfaceimplemented by the exchange manager 124. For example, the provider of alisting 202 may publish the URLs for its listings 202 in order topromote usage of its listing 202 and its brand.

FIG. 3 illustrates various components 300-310 that may be included inthe exchange manager 124. A creation module (e.g., component) 300 mayprovide an interface for creating listings 202. For example, a web pageinterface to the virtual warehouse 131 that enables a user on one ofdevices 101-104 to select data, e.g. a specific table in user data 150of the user, for sharing and enter values defining some or all of themetadata 204, access controls 206, and filters 208. In some embodiments,creation may be performed by a user by way of SQL commands in an SQLinterpreter executing on the cloud computing platform 110 and accessedby way of a webpage interface on a user device 101-104.

A validation module 302 may validate information provided by a providerwhen attempting to create a listing 202. Note that in some embodimentsthe actions ascribed to the validation module 302 may be performed by ahuman reviewing the information provided by the provider. In otherembodiments, these actions are performed automatically. These functionsmay include verifying that the metadata 204 is consistent with theshared data to which it references, verifying that the shared datareferenced by metadata 204 is not pirated data, personal identificationinformation (PII), personal health information (PHI) or other data forwhich sharing is undesirable or illegal. The validation module 302 mayalso facilitate the verification that the data has been updated within athreshold period of time (e.g., within the last twenty-four hours). Thevalidation module 302 may also facilitate verifying that the data is notstatic or not available from other static public sources. The validationmodule 302 may also facilitate verifying that the data is more thanmerely a sample (e.g., that the data is sufficiently complete to beuseful). For example, geographically limited data may be undesirablewhereas a broader-scope aggregation of data that is not otherwisegeographically limited may still be of use.

The exchange manager 124 may include a search module 304. The searchmodule 304 may implement a webpage interface that is accessible by auser on user devices 101-104 in order to invoke searches for searchstrings with respect to the metadata in the catalog 220, receiveresponses to searches, and select references to listings 202 in searchresults for adding to the consumed shares 156 of the user record 212 ofthe user performing the search. In some embodiments, searches may beperformed by a user by way of SQL commands in an SQL interpreterexecuting on the cloud computing platform 102 and accessed by way of awebpage interface on user devices 101-104. For example, searching forshares may be performed by way of SQL queries against the catalog 220within the SQL engine 310 discussed below.

The search module 304 may further implement a recommendation algorithm.For example, the recommendation algorithm could recommend other listing202 for a user based on other listings in the user's consumed shares 156or formerly in the user's consumed shares. Recommendations could bebased on logical similarity: one source of weather data leads to arecommendation for a second source of weather data. Recommendationscould be based on dissimilarity: one listing is for data in one domain(geographic area, technical field, etc.) results in a listing for adifferent domain to facilitate complete coverage by the user's analysis(different geographic area, related technical field, etc.).

The exchange manager 124 may include an access management module 306. Asdescribed above, a user may add a listing 202. This may requireauthentication with respect to the provider of the listing 202. Once alisting 202 is added to the consumed shares 156 of the user record 212of a user, the user may be either (a) required to authenticate each timethe data referenced by the listing 202 is accessed or (b) beautomatically authenticated and allowed to access the data once thelisting 202 is added. The access management module 306 may manageautomatic authentication for subsequent access of data in the consumedshares 156 of a user in order to provide seamless access of the shareddata as if it was part of the user data 150 of that user. To that end,the access management module 306 may access access controls 206 of thelisting 202, certificates, tokens, or other authentication material inorder to authenticate the user when performing accesses to shared data.

The exchange manager 124 may include a joining module 308. The joiningmodule 308 manages the integration of shared data referenced by consumedshares 156 of a user with one another, i.e. shared data from differentproviders, and with a user database 152 of data owned by the user. Inparticular, the joining module 308 may manage the execution of queriesand other computation functions with respect to these various sources ofdata such that their access is transparent to the user. The joiningmodule 308 may further manage the access of data to enforce restrictionson shared data, e.g. such that analysis may be performed and the resultsof the analysis displayed without exposing the underlying data to theconsumer of the data where this restriction is indicated by the accesscontrols 206 of a listing 202.

The exchange manager 124 may further include a standard query language(SQL) engine 310 that is programmed to receive queries from a user andexecute the query with respect to data referenced by the query, whichmay include consumed shares 156 of the user and the user data 112 ownedby the user. The SQL engine 310 may perform any query processingfunctionality known in the art. The SQL engine 310 may additionally oralternatively include any other database management tool or dataanalysis tool known in the art. The SQL engine 310 may define a webpageinterface executing on the cloud computing platform 102 through whichSQL queries are input and responses to SQL queries are presented.

Referring to FIG. 4A, the illustrated method 400 may be executed by theexchange manager 124 in order to implement a point-to-point sharebetween a first user (“provider 402”) and a second user (“consumer404”).

The method 400 may include the provider entering 406 metadata. This mayinclude a user one of devices 101-104 of the provider entering themetadata into fields of a form in a web page provided by the exchangemanager 124. In some embodiments, entering 406 of metadata may be madeusing SQL commands by way of the SQL engine 310. The items of metadatamay include some or all of those discussed above with respect to themetadata 204 of a listing 202. Step 406 may include receiving other datafor a listing 202, such as access controls 206 and parameters defining afilter 208.

The provider 402 may then invoke, on the devices 101-104, submission ofthe form and the data entered.

The exchange manager 124 may then verify 408 the metadata and validate410 the data referenced by the metadata. This may include performingsome or all of the actions ascribed to the validation module 302.

If the metadata and shared data are not successfully verified 408 andvalidated 410, the exchange manager 124 may notify the provider 402,such as by means of a notification through the web interface throughwhich the metadata was submitted at step 406.

If the metadata and shared data are not successfully verified 408 andvalidated 410, the exchange manager 124 may notify the provider 402,such as by way of the web interface through which the metadata wassubmitted at step 406.

The exchange manager 124 may further create 412 a listing 202 includingthe data submitted at step 406 and may further create an entry in thecatalog 220. For example, keywords, descriptive text, and other items ofinformation in the metadata may be indexed to facilitate searching.

Note that steps 406-412 may be performed by means of an interfaceprovided to the provider 402. Such an interface may include any suitablefeatures including elements for inputting data (e.g., elements 204-210),and elements for generating a data listing. In addition, the interfacemay include elements to publish or unpublish a data listing to make thelisting un-viewable to at least some other users. The interface may alsoinclude an element to update versions of the data listing or to rollback to a prior version of the listing or of the metadata associatedwith the listing. The interface may also include a list of pendingrequests to add a data listing or to add members to the data exchange.The interface may also include an indication of the number and othernon-identifying information related to the data consumers who haveaccessed a given listing, as well as a representation of usage patternsof the data referenced by a listing by the data consumers of thatlisting.

Another user acting as a consumer 404 may then browse 414 the catalog.This may include accessing a publicly accessible web page providing asearch interface to the catalog. This webpage may be external to thevirtual warehouse 131, i.e. accessible by users that are not logged intothe virtual warehouse 131. In other embodiments, only users that arelogged in to the virtual warehouse 131 are able to access the searchinterface. As noted above, browsing of the catalog 220 may be performedusing queries to the SQL engine 310 that reference the catalog 220. Forexample, user devices 101-104 may have a web-based interface to the SQLengine 310 through which queries against the catalog 220 are input bythe consumer 404 and transmitted to the SQL engine 310.

In response to the consumer's browsing activities, the exchange manager124 may display the catalog and perform 416 searches with respect to thecatalog to identify listings 202 having metadata corresponding toqueries or search strings submitted by the consumer 404. The manner inwhich this search is performed may be according to any search algorithmknown in the art. In the case of an SQL query, the query may beprocessed according to any approach for processing SQL queries known inthe art.

The exchange manager 124 may return results of a search string or SQLquery to the consumer's 404 devices 101-104, such as in the form of alisting of references to listings 202 identified according to the searchalgorithm or processing the SQL query. The listing may include items ofmetadata or links that the consumer 404 may select to invoke display ofmetadata. In particular, any of the items of metadata 204 of a listing202 may be displayed in the listing or linked to by an entry in thelisting corresponding to the search record 202.

Note that the exchange referenced in FIG. 4A may be a private exchangeor a public exchange. In particular, those listings 202 that aredisplayed and searched 416 and viewable by the consumer 404 duringbrowsing 414 may be limited to those having filters 208 that indicatethat the listing 202 is viewable by the consumer 404, an organization ofthe consumer, or some other classification to which the consumer 404belongs. Where the exchange is public, then the consumer 404 is notrequired to meet any filter criteria in some embodiments.

The method 400 may include the consumer 404 requesting 418 to accessdata corresponding to a listing 202. For example, by selecting an entryin the listing on the devices 101-104 of the consumer 404, which invokestransmission of a request to the exchange manager 124 to add the listing202 corresponding to the entry to the consumed shares 156 in the userrecord 212 of the consumer 404.

In the illustrated example, the listing 202 of the selected entry hasaccess controls 206. Accordingly, the exchange manager 124 may forward420 the request to the provider 402 along with an identifier of theconsumer 404. The consumer 404 and provider 402 may then interact to oneor both of (a) authenticate (login) 424 the consumer 404 with respect tothe provider 402 and (b) process 424 payment for access of the datareferenced by the listing 202. This interaction may be according to anyapproach to logging in or authenticating or known in the art. Likewise,any approach for processing payment between parties may be implemented.In some embodiments, the data warehouse module may provide a rebate tothe provider 402 due to credits consumed by the consumer 404 whenaccessing the shared data of the provider. Credits may be units of usagepurchased by a user that are then consumed in response to services ofthe virtual warehouse 131 used by the consumer 404, e.g. queries andother analytics performed on data, or storage of data hosted by thevirtual warehouse 131. The interaction may be directly between devices126 of the consumer 404 and provider 402 or may be performed by way ofthe exchange manager 124. In some embodiments, the exchange manager 124authenticates the consumer 404 using the access control information 206such that interaction with the provider 402 is not needed. Likewise, thelisting 202 may define payment terms such that the exchange manager 124processes payment without requiring interaction with the provider 402.Once the provider 402 determines that the consumer 404 is authenticatedand authorized to access the data referenced by the listing 202, theprovider 402 may notify 426 the exchange manager 124 that the consumer404 may access the data referenced by the listing 202. In response, theexchange manager 124 adds 428 a reference to the listing 202 to theconsumed shares 156 in the user record 212 of the consumer 404.

Note that in some instances a listing 202 does not list specific data,but rather references a particular cloud service 120, e.g. the brandname or company name of a service. Accordingly, the request to accessthe listing 202 is a request to access user data 150 of the consumermaking the request. Accordingly, steps 422, 424, 426 includingauthenticating the consumer 404 with respect to the authenticationengine 121 such that the cloud service 120 can verify the identity ofthe consumer 404 and inform the exchange manager 124 of which data toshare with the consumer 404 and to indicate that the consumer 404 isauthorized to access that data.

In some embodiments, this may be implemented using a “single sign on”approach in which the consumer 404 authenticates (logs in) once withrespect to the cloud service 120 and thereafter is enabled to access theconsumers 404 data in the service database 158. For example, theexchange manager 124 may present an interface to the cloud service 120on the devices 101-104 of the consumer 404. The consumer 404 inputsauthentication information (username and password, certificate, token,etc.) into the interface and this information is forwarded to theauthentication engine 121 of the cloud service 120. The authenticationinformation processes the authentication information and, if theinformation corresponds to a user account, notifies the exchange manager124 that the consumer 404 is authenticated with respect to that useraccount. The exchange manager 124 may then identify the user data 150for that user account and create a database referencing it. A referenceto that database is then added to the consumed shares 156 of theconsumer 404.

In some embodiments, the user's authentication with respect to thevirtual warehouse 131 is sufficient to authenticate the user withrespect to the cloud service 120 such that steps 422, 424 are omitted inview of the prior authentication of the consumer 404. For example, thevirtual warehouse 131 may be indicated by the consumer 404 to the cloudservice 120 to be authorized to verify the identity of the consumer 404.

In some embodiments, the exchange manager 124 authenticates the consumer404 using the access control information 206 such that interaction withthe provider 402 is not needed. Likewise, the listing 202 may definepayment terms such that the exchange manager 124 processes paymentwithout requiring interaction with the provider 402. Accordingly, insuch embodiments, step 422 is performed by the exchange manager 124 andstep 426 is omitted. The exchange manager 124 then performs step 428once the consumer 404 is authenticated and/or provided required payment.

In some embodiments, adding a listing 202 to the consumed shares of aconsumer 404 may further include receiving, from the consumer 404,consent to terms presented to the consumer 404. In some embodiments,where the terms of the agreement are changed by a provider 402 after aconsumer 404 has added the listing 202 according to the method 400 orother methods described herein, the exchange manager 124 may require theconsumer 404 to agree to the changed terms before being allowed tocontinue to access the data referenced by the listing 202.

Adding 428 the data reference by the listing 202 may include creating adatabase referencing the data. A reference to this database may then beadded to the consumed shares 156 and this database may then be used toprocess queries referencing the data referenced by the share record.Adding 428 the data may include adding data filtered according tofilters 208. For example, data referenced by the listing 202 (e.g., afiltered view of the data) and that is associated with the consumer 404,organization of the consumer 404, or some other classification of theconsumer 404.

In some embodiments, adding the listing 202 to the user record 212 mayinclude changing the access controls 206 of the listing 202 to referencethe identity data 214 of the consumer 404 such that attempts to accessthe data referenced by the listing 202 will be permitted and executed bythe exchange manager 124.

The consumer 404 may then input 432 queries to the SQL engine 310 by wayof the consumer's devices 101-104. The queries may reference the datareferenced in the listing 202 added at step 428 as well as other datareferenced in the user database 152 and consumed shares 156. The SQLengine 310 then processes 430 the queries using the database created atstep 428 and returns the result to the consumer 404 or creates views,materialized views, or other data that may be accessed or analyzed bythe user. As noted above, the data of consumed shares operated upon bythe queries may have been previously filtered to include only datarelating to the consumer 404. Accordingly, different consumers 404adding the same listing 202 to their consumed shares 156 will seedifferent versions of the database referenced by the listing 202.

Referring to FIG. 4B, in some embodiments, the private sharing of dataand filtering of data may be implemented using the illustrated datastructures. For example, the service database 158 of the provider 402may include a customer map 434 that includes entries for customeridentifiers 436 of users of the service provided by the provider 402,e.g., a service implemented by the cloud service 120 of the server andthe customer identifier 436 being an identifier for authenticating withthe authentication interface 120. The customer map 434 may map eachcustomer identifier 436 to a warehouse identifier 438, i.e. a useridentifier used by a user to authenticate with the virtual warehouse 131such that the same user corresponds to both identifiers 436, 438. Themapping between the identifiers 436 and 438 may be performed byauthenticating as described above (e.g., the single sign on approachdescribed above).

The customer map 434 may further include a reference 440 to anentitlement table 442, which may be one of a plurality of entitlementtables 442. Each entitlement table 442 defines which of one or more rowsof tables 444 of the provider 402 may be accessed with the customer ID436 to which it is mapped. The entitlement table 442 may further definecolumns of a table 444 that can be accessed with the customer ID 436.The entitlement table 442 may further define rows or types of rows basedon one or more filtration criteria of a table 444 that can be accessedwith the customer ID 436. The entitlement table 442 may further define aschema for a table 444 that can be accessed with the customer ID 436.

A listing 202 for a table 444 may therefore specify that access to adata table 444 is to be performed as defined by the customer map 434.For example, referring to FIG. 4C, when a consumer 404 requests to add alisting 202 for a database for which access is defined according to thecustomer map, the exchange manager 124 may create a secure view 446according to the customer identifier 436 and entitlement table 442mapped to the warehouse identifier 438 of the consumer 404. The secureview may be generated by performing an inner join of the data tables 444of the database specified in the secure view definition (or portionsthereof as specified in the secure view definition) that is filteredaccording to the customer identifier 436, such that the result of thejoin includes only data for the specific customer identifier 436 andincludes only those portions of the database (tables 444 and/or portionsof tables 444) specified in the secure view definition. The manner inwhich the secure view is generated may be as described in U.S.application Ser. No. 16/055,824 filed Aug. 6, 2018, and entitled SECUREDATA SHARING IN A MULTI-TENANT DATABASE and U.S. application Ser. No.16/241,463 filed Jan. 7, 2019 and entitled SECURE DATA SHARING IN AMULTI-TENANT DATABASE.

FIG. 5 illustrates an alternative method 500 for sharing data that maybe performed when the consumer requests 418 to add a listing 202 that isavailable to the public or to all users of a private exchange. In thatcase, the exchange manager 124 adds 428 the reference to the listing 202to the consumed shares 156 of the consumer 404 and authentication orpayment steps are omitted. Step 428 may be performed as described aboveexcept that no change to access controls 206 is performed. Likewise,steps 430 and 432 may be performed with respect to the shared data asdescribed above. The exchange of FIG. 5 could be a public exchange or aprivate exchange as described above with respect to FIG. 4. FIG. 5illustrates the case where if a listing 202 is viewable (i.e. filtercriteria permit viewing by the consumer 404 as described above), theconsumer 404 is able to add the listing 202 to the consumed shares 156of the consumer 404 without further authentication or payment.

Note that when a listing 202 is added to the consumed shares 156 of auser according to any of the methods disclosed herein, the exchangemanager 124 may notify consumers of the listing 202 when the datareferenced by the listing 202 is updated.

Referring to FIG. 6, in some embodiments, a method 600 may include aconsumer 404 browsing a catalog and selecting a listing 202 as describedfor the other methods described herein (see, e.g., FIGS. 4A and 5), fromthe exchange manager 124, a bidirectional share with respect to the datareferenced by the listing (“the shared data”) and additional data in theuser's database 112 (“the user's data”). Note that in some embodimentsthe listing 202 of the provider 402 does not reference any specific data(e.g., a specific table or database) and instead offers to perform aservice with respect to data provided by the consumer 404. Accordingly,in such instances “the shared data” as discussed below may be understoodto be replaced with “the offered service.”

In response to this request, the exchange manager 124 implements 604 apoint-to-point share of the shared data with respect to the consumer 404and the provider 402. This may be performed as described above withrespect to FIG. 4A, e.g. include authentication of the consumer 404 andpossibly filtering of the shared data to only include data associatedwith the consumer 404 as described above. The exchange manager 124 mayfurther implement a point-to-point share of the user's data with respectto the provider 402 as described with respect to FIG. 4A except: (a) theconsumer 404 acts as the provider and the provider 402 acts as theconsumer for the user's data and the user's data is added to theconsumed shares 156 of the provider 402 and (b) the consumer 404 neednot create a listing 202 for the user's data and the user's data neednot be listed in the catalog 220.

Following step 606, both the consumer 404 or the provider 402 haveaccess to the shared data and the user's data. Either may then runqueries against both of these, join them, cross-filter, performaggregations on the joined data, or perform any other actions known inthe art with respect to multiple databases.

In some embodiments, a bi-directional share may include, or be requestedby the consumer 404 to include, the provider 402 also joining 608 theshared data and the user data to obtain joined data and returning 610 areference to the joined data to the exchange manager 124 with a requestto add 612 a reference to the joined data to the consumed shares 156 ofthe consumer 404, which the exchange manager 124 does.

Accordingly, the consumer 404 will now have access to the joined data.Step 608 may further include performing other actions (aggregations,analysis) on the user data and shared data either before or afterjoining. Step 608 may be performed by the virtual warehouse 131 inresponse to the request form the consumer 404 to do so.

Note that the result of the join may be either (a) a new database thatis a result of the join or (b) a joined database view that defines ajoin of the shared data and the user data.

The result from step 608 (joining, aggregating, analyzing, etc.) mayalternatively be added to the original share performed at step 606, 608,e.g. a view (materialized or non-materialized) defining the operationsperformed at step 608.

Steps 608-612 may also be performed by the virtual warehouse 131 inresponse to a request from the consumer 404 or provider 402 to do soindependently from the request made at step 602.

Note that in many instances there are many consumers 404 that attempt toperform bi-directional shares with respect to the provider 402 and theseconsumers 404 may seek bi-directional shares with respect to their userdata that may be in many different formats (schemas) that may bedifferent from a schema used by the shared data of the provider 402.Accordingly, step 608 may include a transformation step. Thetransformation step maps a source schema of the user's data to a targetschema of the shared data. The transformation may be a statictransformation provided by a human operator. The transformation may beaccording to an algorithm that maps column labels of the source schemato corresponding column labels of the target schema. The algorithm mayinclude a machine learning or artificial intelligence model that istrained to perform the transformation. For example, a plurality oftraining data entries may be specified by human annotators that eachinclude as an input a source schema and as an output include a mappingbetween the source schema and the target schema. These entries may thenbe used to train a machine learning or artificial intelligence algorithmto output a mapping to a target schema for a given input source schema.

Data added to the shares consumed by the consumer 404 and provider 402may then be operated on by the consumer 404 and provider 402,respectively, such as by executing queries against the data, aggregatingthe data, analyzing the data, or performing any other actions describedherein as being performed with respect to shares added to the consumedshares 156 of a user.

In particular embodiments, a data provider may improve its relationshipwith business partners by enabling the secure interchange of data in abi-directional manner, as discussed above. Traditional methods ofbi-directional data sharing have been challenging to accomplish, andonly very limited sets of data are shared via APIs, FTP, or filetransfer between companies. And this often comes at great cost, expense,data latency, and even some security risk.

A data provider may instead host a private data exchange, and invitetheir customers and partners to participate in the exchange. Customersand partners may access data in secure views, for example, and they mayalso push data in the other direction as well. This could be to sharedata back to the host, but also to potentially list data so that otherparticipants of the ecosystem can securely share it as well. Data from apublic data exchange, other private exchanges, or from other externalsources may also be included.

Every large company depends on other companies, and on its customers.Bidirectionally sharing data not only from the company to and from theseparties, but also between these external parties themselves, can allowrich, collaborative data ecosystems to develop where groups of companiescan work together around data. They can securely discover, combine, andenrich data assets to help service a common customer, or to form newpartnerships amongst themselves. Some of these relationships may evenlead to opportunities to sell data, secure views of or functions acrossdata to other participants of a walled garden ecosystem.

Referring to FIG. 7, the approach to sharing and consuming data asdescribed herein enables enrichment of data and return of that enricheddata to the exchange. For example, provider A may request 702 sharing ofdata (share 1) with the exchange in the same manner as for other methodsdescribed herein. The exchange manager 124 verifies, validates, and adds704 share 1 to the catalog 220.

A second provider B may then browse the catalog 220 and add 706 share 1to its consumed shares 156. Provider B may perform 708 operations on theshared data such as joining it with other data, performing aggregations,and/or performing other analysis with respect to share 1, resulting inmodified data (share 2). Provider B may then request 710 sharing ofshare 2 with the exchange as described herein. Note that the joining ofstep 708 may include joining any number of databases, such as any numberof shares based on any number of listings by any number of other users.Accordingly, iterations of steps 702-710 by many users may be viewed asa hierarchy in which a large number of listings 202 of multiple usersare narrowed down to a smaller number of listings 202 based on the datafrom the larger number of listings 202.

The exchange manager 124 verifies, validates, and adds 712 share 2 tothe catalog 220. This process may be repeated 714 with respect to share2, as provider A, provider B, or a different provider adds share 2,generates modified data based on it, and adds the result back to thecatalog in the same manner. In this manner, a rich ecosystem of data andanalysis may be made available to users. The shares according to themethod 700 may be shares available to all exchange members,point-to-point shares, private exchange shares, or bi-directionalexchange shares according to the methods disclosed herein.

Note that there is a possibility that provider may perform steps 708 and710 with respect to a listing 202 that is based on a listing 202. Forexample, listing L1 of provider A is used by provider B to createlisting L2, which is used by provider C to create listing L3, which isused by provider A to define listing L1. Such a flow could include anynumber of steps. This may be undesirable in some cases such thatmodification of listing L1 to reference L3 is not permitted in view L3being derived from L1. In other instances, such a loop is permittedprovided there is a time delay in when the data referenced by eachlisting is refreshed. For example, L1 may reference L3 provided L3 willnot be refreshed until sometime after L1 is refreshed and therefore thecircular reference will not result in continuous updating of L1 and L3ad infinitum. Non-looping flows are also contemplated by thisdisclosure, such that listing L1 is not influenced by other providers'use of listing L1.

The listing created at step 712 (Share 2) may either (a) include copiesof the data from Share 1 remaining after step 708 and as modifiedaccording to step 708 or (b) include a view referencing Share 1 (e.g., adatabase created based on the listing 202 for Share 1 according to themethods disclosed herein) and defining the operations performed at step708 without including actual data from Share 1 or derived from Share 1.Accordingly, a hierarchy as described above may be a hierarchy of viewsthat either reference one or both of listing 202 that are views createdaccording to the method 700 or listing 202 of data from one or moreproviders according to any of the methods disclosed herein.

In the methods disclosed herein approaches are disclosed for creatingshares (listings 202) and for adding shares. In a like manner, aconsumer 404 may instruct the exchange manager 124 to remove addedshares. A provider 402 may instruct the exchange manager 124 to ceasesharing certain listings 202. In some embodiments, this may beaccompanied by actions to avoid disrupting consumers 404 of thoselistings 202. Such as by notifying these consumers 404 and ceasing toshare the listings 202 only after a specified time period after thenotification or after all consumers 404 have removed references to thelistings 202 from their consumed shares 156.

Use Cases

In a first use case a company implements a private exchange according tothe methods described above. In particular, listing 202 of the companyare viewable only by consumers 404 that are associated (employees,management, investors, etc.) with the company. Likewise, adding oflisting 202 is permitted only for those associated with the company.When adding a listing 202 to the consumed shares 156, it may be filteredbased on the identity of the consumer that adds it, i.e. data that isrelevant to the consumer's role within the company and/or the purpose oftheir analysis.

In a second use case, a provider 402 creates a reader or reader/writeraccount for a consumer 404 that may not be a user of the virtualwarehouse 131. The account may be associated with the account data ofthe consumer (see consumer map of FIG. 4B discussed above). The consumer404 may then log on to that account and then access the provider'slistings to access the consumer's data 404 that is managed by theprovider 402 (see, e.g. discussion of FIG. 4A).

In a fifth use case a consumer 404 adds shares that are private (e.g.,accessible due to the identity of the consumer 404 according to themethods described above) and shares that are public. These may then bejoined by the consumer 404 and used to process queries.

In a sixth use case, a listing 202 may be shared base on a subscription(e.g., monthly) or be accessed based on per-query pricing, or a credituplift multiplier. Accordingly, the exchange manager 124 or provider ofthe virtual warehouse may manage processing of payment and access suchthat the consumer 404 is allowed to access the data subject to thepricing model (subscription, per query, etc.).

In a seventh use case, the exchange manager 124 implements securefunctions and secure machine learning models (both training and scoring)that may be used to process private data such that the consumer 404 isallowed to use the result of the function or machine learning model butdoes not have access to the raw data processed by the function ormachine learning model. Likewise, the consumer of the shared data is notallowed to export the underlying data. The consumer is nonethelessallowed to perform analytical functions with respect to the shared data.For example, the following secure function may be implemented to enableviewing of customer shopping data in a secure manner:

-   -   select 6139 as input_item, ss_item_sk as basket_Item,        count(distinct ss_ticket_number)    -   baskets    -   from udf_demo.public.sales    -   where ss_ticket_number in (select ss_ticket_number from        udf_demo.public.sales where ss_item_sk=6139)    -   group by ss_item_sk    -   order by 3 desc, 2;

In an eighth use case, the exchange manager 124 may provide usagestatistics of a listing 202 by one or more consumers 404 to the provider402 of the listing, e.g. queries, credits used, tables scanned, tableshit, etc.

In a ninth use case, the systems and methods disclosed herein are usedfor industry-specific applications. For example:

1. Cybersecurity

-   -   a. Allows for sharing of risk vectors, bad actors, IP        white/black lists, realtime attacks in progress, known good/bad        emailers, etc.

2. Healthcare

-   -   a. Secure sharing of patient information, including cost        information and outcome information, among other types of        information    -   b. Secure multi-hospital databases so patients can share their        information to multiple providers. (e.g., if patient A lives in        California and travels to Florida on vacation, is injured, and        is treated in an emergency room, the hospital in Florida may be        able to access patient A's records from disparate hospitals and        providers.)

Other industries may also benefit from private or public sharing of dataaccording to the systems and methods disclosed herein. Such as thefinancial services industry, telecommunications industry, media andadvertising industry, government agencies, militaries, and intelligenceagencies.

In a tenth use case, a first user provides marketing services for asecond user, and therefore the second user shares a customer list withthe first user. The first user shares data regarding a marketingcampaign to the second user, such as campaign metadata, current userevents (session start/end for specific users, purchases for specificusers, etc.). This may be accomplished using the bi-directional sharingof FIG. 6. This data may be joined (customer list+customer events fromfirst user) in order to obtain a better understanding about events for aspecific user or groups of users. As noted above, this exchange of datamay be performed without creating copies or transferring data—each useraccesses the same copy of the shared data. Since no data is transferred,the data may be accessed in near real time as customer events occur.

FIG. 8 is a block diagram illustrating a network environment in which adata provider may share data via a cloud computing service. A dataprovider 810 may upload one or more data sets 820 in cloud storage usinga cloud computing service 112. These data sets may then become viewableby one or more data consumers 101-104. The data provider 810 may be ableto control, monitor, and increase the security of its data using thecloud computing service 112 using the methods and systems discussedherein. In particular embodiments, the data provider 810 may implement aprivate data exchange on its own online domain using the functionality,methods, and systems provided by cloud computing service 112. Dataproviders 810 may be any provider of data, such as retail companies,government agencies, polling agencies, non-profit organizations, etc.The data consumers 101-104 may be internal to the data provider 810 orexternal to the data provider 810. A data consumer that is internal tothe data provider may be an employee of the data provider. The dataprovider may be a bike-share company, which provides bicycles for adaily, monthly, annual, or trip-based fee. The bike share company maygather data about its users, such as basic demographic information aswell as ride information, including date of ride, time of ride, andduration of ride. This information may be available to employees of thebike share company via the cloud computing service 112.

The interaction between a data provider 810, private data exchange 812(as implemented by cloud computing service 112), and a data consumer maybe as follows. The data provider may create one or more listings 811using data sets 820. The listings may be for any suitable data. Forexample, a consumer data company may create a listing called “videostreaming” that contains data related to the video streaming habits of alarge number of users. The data provider may set listing policies 821related to who may view the listing 811, who may access the data in thelisting 811, or any other suitable policy. Such listing policies arediscussed above with reference to FIG. 2. The data provider 810 may thensubmit to the private exchange 812 at step 813. The private dataexchange 812 may be embedded inside a web domain of the data provider810. For example, if the web domain of the consumer data company iswww.entityA.com, the private data exchange may be found atwww.entityA.com/privatedataexchange. The private data exchange 812 mayreceive the listing and approve it at step 814 if the listing complieswith one or more rules as determined by the cloud computing service 112.The private data exchange 812 may then set up access controls at 815 atleast in part according to the listing policies what were set in step821. The private data exchange 812 may then invite members at step 816.The members may be data consumers 801. The data consumers 801 may acceptthe invitation at step 817 and then may begin consuming the data at 818.The type of data consumption may depend on the access controls that wereestablished at 815. For example, the data consumer may be able to readthe data only or share the data. As another example, a data consumer maybe able to do any combination of the above read, or share operations onthe data, subject to the access controls. In general, data sharing doesnot involve altering shared data.

In some embodiments, a data consumer 801 may independently access theprivate data exchange 812, either by directly navigating to the privatedata exchange 812 in a browser, or by clicking on an advertisement forthe private data exchange 812, or by any other suitable mechanism. Aprivate data exchange may also be rendered via custom or other code byaccessing listing and other information via an API. If the data consumer801 wishes to access the data within a listing and the listing is notalready universally available or the data consumer 801 does not alreadyhave access, the data consumer 801 may need to request access at step820. The data provider may approve or deny the request at 822. Ifapproved, the private data exchange may grant access to the listing at823. The user may then begin consuming the data as discussed above.

In particular embodiments, one or more data exchange administrators maybe designated by the cloud computing service 112. The data exchangeadministrator may manage members of the private data exchange bydesignating members as data providers 810 or data consumers 801. Thedata exchange administrator may be able to control listing visibility byselecting which members can see a given listing. The data exchangeadministrator may also have other functions such as approving listingsbefore they are published on the private data exchange, track usage ofeach of the listings, or any other suitable administrative function. Insome embodiments, the data provider and the data exchange administratorare part of the same entity; in some embodiments, they are separateentities. The provider may create listings, may test sample queries onthe data underlying a listing, may set listing access, grant access tolisting requests, and track usage of each of the listings and the dataunderlying the listings. A data consumer 801 may visit a private dataexchange and browse visible listings which may appear as tiles. Toconsume the data underlying a listing, the consumer may eitherimmediately access the data, or may request access to the data.

FIG. 9 is an example private data exchange 900 in accordance with anembodiment of the present invention. Private data exchange 900 may bewhat a data consumer sees when she navigates to the private dataexchange on the web. For example, the data consumer may enterwww.entityA.com/privatedataexchange in her browser. As discussed herein,“Entity A Data Exchange” may be a private data exchange that isfacilitated by the cloud computing service 112 and is embedded intoEntity A's own web domain or into an application, accessible via a clouddata warehouse, or may be accessed via an API. Private data exchange 900may include several listings for different data sets, for examplelistings A-L. The listing A-L may also be referred to herein as a datacatalog, which may allow visitors to the private data exchange to viewall the available listings in the private data exchange. These listingsmay be placed by an administrator internal to Entity A. Providing a datacatalog in this manner may serve to combine the benefits of crowdsourcedcontent, data quality, and the right level of centralized control andcoordination that can overcome the challenges that have slowed theadoption of other approaches to enterprise data cataloging (e.g.,indexing and crawling systems). It allows users across an enterprise tocontribute data, use data from other groups, and join data together tocreate enriched data products, for both internal use as well aspotentially for external monetization.

As an example and not by way of limitation, Entity A may be a consumerdata company that has collected and analyzed the consuming habits ofmillions of individuals in several different categories. Their data setsmay include data in the following categories: online shopping, videostreaming, electricity consumption, automobile usage, internet usage,clothing purchases, mobile application purchases, club memberships, andonline subscription services. Each of these data sets may correspond todifferent listings. For example, Listing A may be for online shoppingdata, Listing B may be for video streaming data, Listing C may be forelectricity consumption data, and so on. Note that the data may beanonymized so that individual identities are not revealed. The listingslocated below line 915 may correspond to third-party listings thatentity A may allow on its private data exchange. Such listings may begenerated by other data providers and may be subject to approval byEntity A before being added to the private data exchange 900. A dataconsumer may click on and view any of the listings subject to variousaccess controls and policies as discussed above with reference to FIGS.2, 4, and 8.

In particular embodiments, a data provider may invite members to accessits private data exchange, as discussed with reference to FIG. 8. Oneclass of members may be the physical and digital supply chain suppliersof the data provider. For example, a data provider may share data withsuppliers on its inventory levels or consumption of things provided bythe suppliers, so they can better meet the needs of the data provider.In addition, digital data providers may provide data directly into itsprivate data exchange, to make it immediately usable and joinable to theinternal enterprise data, saving costs for both parties on transmitting,storing, and loading the data.

Some companies such as hedge funds and marketing agencies bring in datafrom many external sources. Some hedge funds evaluate hundreds ofpotential data sets per year. A private data exchange may be used to notonly connect with data that has already been purchased, but can also beused to evaluate new data assets. For example, a hedge fund could havepotential data suppliers list their data on their private exchange, andthe fund could explore and “shop” for data in a private data store wherethey are the only customer. Such an internal data store could also“tunnel” in data assets from a public Data Exchange (e.g., the SNOWFLAKEpublic Data Exchange), as discussed with reference to FIG. 11.

As another example, an existing provider of marketing data to a companycould list some additional datasets that their customer could use viatheir private exchange on a trial basis, and if the customer finds themuseful, the supplier can immediately provide full access through thesame exchange. These arrangements can bring much greater depth of data,bi-directional and much fresher data, and greater trust and transparencyto relationships between suppliers of data and physical goods and theircustomers.

FIG. 10 is a diagram illustrating an example secure view of shared datafrom a private data exchange. When a data consumer 1020 wishes to accessdata in a listing (e.g., Listing H), the cloud computing service 112 mayfacilitate access via a secure view of shared data 1010. The secure viewof shared data 1010 may include metadata 1015 that includes the metadataand access controls discussed herein with reference to FIG. 2. This mayallow data providers to share data without exposing the underlyingtables or internal details. This makes the data more private and secure.With a secure view of shared data 1010, the view definition and detailsare only visible to authorized users.

In a private data exchange, data may be shared both within the sameentity and between different entities. Additionally, the data sharingmay be one-way, two-way, or multi-way. This leads to five main use-casesfor sharing data: two-way inter-entity, two-way intra-entity, one-wayinter-entity, one-way intra-entity, and multi-way multi-entity. Anexample of two-way inter-entity data sharing may be data sharing fromportfolio companies to a parent company and between portfolio companies.An example of two-way intra entity data sharing may be data sharing fromthe headquarters of a large company to the different business unitswithin that company, and also data sharing from the business units toheadquarters. An example of one-way inter-entity data sharing may be alarge data provider (e.g., a national weather service) that shares datawith lots of different entities, but does not receive data from thoseentities. An example of one-way intra-entity may be a large company thatprovides data to its respective business units but does not receive datafrom those business units. In particular embodiments, data may be sharedas “point-to-point shares” of specific data, or as “any-shares”. Apoint-to-point share of specific data may include a private dataexchange share between a parent company and specific portfoliocompanies. An any-share may include a private data exchange share from aparent company to a broad group of data consumers on a public or withina private exchange.

In particular embodiments, the cloud computing service 112 may generatea private data exchange for an entity who is the owner of the data to beshared on the private data exchange. The cloud computing service 112 maydesignate one or more administrators of the private data exchange. Theseadministrators may have control over the access rights of the privatedata exchange with regard to other users. For example, an administratormay be able to add another user account to the private data exchange anddesignate that account as a data provider, data consumer, exchangeadministrator, or a combination of these.

In particular embodiments, the exchange administrator may controlviewing and access rights to the private data exchange. Viewing rightsmay include a list of entities that may view the listing in the privatedata exchange. Access rights may include a list of entities that mayaccess the data after selecting a particular listing. For example, acompany may publish private data exchange 900 and may include severallistings, Listing A through Listing L. Each of these listings mayinclude their own individual viewing and access rights. For example,Listing A may include a first list of entities that have rights to viewthe listing on the private data exchange 900 and a second list ofentities that have rights to access the listing. Viewing a listing maysimply be to see that the listing exists on the private data exchange.Accessing a listing may be to select the listing and access theunderlying data for that listing. Access may include both viewing theunderlying data, manipulating that data, or both. Controlling viewingrights may be useful for data providers who do not want some users toeven know that a certain listing exists on the private data exchange.Thus, when a user who does not have viewing rights to a particularlisting visits the private data exchange, that user will not even seethe listing on the exchange.

In particular embodiments, the above discussed viewing and access rightsmay be provisioned via an application program interface (API). Theexchange catalog may be queries and updated via the API. This may allowa data provider to show listings on its own application or website toanyone who visits. When a user wants to access or request access todata, the user may then create an account with the cloud computingservice 112 and obtain access. In some embodiments, a URL may be calledwith a user requests access to data within a listing. This may allow forintegration with external request approval workflows. For example, if auser makes an access request, an external request approval workflow ofthe data provider may be accessed and activated. The external requestapproval workflow may then operate normally to perform an externalrequest approval process. In some embodiments, the private data exchangeadministrator may be able to designate which cloud computing platform110 will store their data. In some embodiments, a listing may beunlisted, which means that the listing exists but is not visible on thedata exchange. To access an unlisted listing, a consumer may input aglobal URL into the browser. This may require a unique URL for eachlisting.

In particular embodiments, when a new private data exchange is createdfor a data provider, the cloud computing service 112 may designate anexchange admin (e.g., the data exchange administrator, as discussedabove), and may also generate the following metadata about the privatedata exchange: the name of the private data exchange, which needs to beunique, a display name, a logo, a short description of the private dataexchange, and an indication of whether approval from the exchange adminis necessary for publishing (e.g., Admin Approval for Publishing). Thismay be a true/false statement. It may be set to true if the exchangeadmin needs to approve listings submitted to the private data exchangebefore they are published. It may be set to false if the exchange admindoes not need to provide such approval. In this case, providers canpublish data directly. If the exchange admin sets the Admin Approval forPublishing to True, the exchange admin may be able to see a list ofListings, and select a listing to preview and approve/reject. The ownerof the private data exchange may be the account that is paying for theprivate data exchange. This metadata information may be stored as partof an Exchange object. Also stored in association with the private dataexchange may be the users and accounts who provide data to the exchange,the consumers of the exchange, and the exchange admin(s).

In particular embodiments, the exchange admin may add members (e.g.,data providers and data consumers) to the private data exchange byinviting the members in any suitable manner. For example, by invitingthe users' accounts on the cloud computing service 112, or by sending anemail to the users' email account addresses. When the exchange adminadds a member to the private data exchange, the exchange admin may alsospecify the member-type: exchange admin, provider, or consumer. Anexchange admin may be able to add and remove members from the privatedata exchange and to edit metadata associated with the private dataexchange. For each user, the exchange admin may designate whether theuser is an exchange admin, a data provider, and a data consumer Thefollowing table summarizes the rights associated with each type ofaccount.

TABLE 1 Rights Associated with Each Type of Private Data ExchangeAccount is_Exchange_Admin is_Data_Provider is_Data_Consumer DescriptionFalse False True Can Discover & Consume listings (subject to Listingvisibility and access rules), but cannot publish listings False TrueTrue Can Discover & Consume listings (subject to Listing visibility andaccess rules), plus can publish listings False True False Can publishlistings, but when they go to the consumer view they only see their ownlistings. True True True Can do everything a data provider and a dataconsumer can do, as well as add members, remove members, change memberroles, access list of member accounts, and edit metadata.

In some embodiments, if the exchange admin removes a member or changes amember's type from provider to a consumer only, then existing listingspublished by that member may become unpublished from the Exchange.Additionally, existing shares added to the Exchange by the member are nolonger considered part of the private data exchange. The listingspublished by that member may be archived, and are no longer visible inthe UI to anyone, including the member. The cloud computing service 112can un-archive this if the same member (same account on the cloudcomputing service 112) who has been removed is made a Provider again.

In some embodiments, the exchange admin may be able to specify a list ofcategories as well as edit an existing list. Categories may have iconsassociated with them, and the exchange admin may be able to specify theicon along with the category name.

When a member becomes a data provider, a provider profile may begenerated that includes a logo, a description of the provider, and a URLto the provider's website. When submitting listings, a provider may dothe following: select which private data exchange to publish the data in(e.g., many private exchanges may exist and the provider may need toselect a subset of these exchanges, which may be one or more), and setmetadata about the new listing. The metadata may include a listingtitle, a listing type (e.g., Standard or Personalized), a listingdescription, one or more usage examples (e.g., title and samplequeries), a listing category, which may be input as free form text, anupdate frequency for the listing, a support email/URL, and adocumentation link. The provider may also set access for the listing.The provider may allow the exchange admin to control the visibility ofthe listing, or the provider may retain that control for itself. Theprovider may also associate a share with a listing. For a standardshare, a listing may be associated with zero or more shares. Theprovider may associate shares to a listing through the UI or SQL. Forpersonalized shares, when the provider provisions a share in response toa request, the provider may associate that share with the listing. Whenthe provider wishes to publish the listing, the listing may first needapproval from the exchange admin, depending on the publishing rules ofthe private data exchange.

FIG. 11 is a diagram illustrating an example tunneling of a data listingbetween a public data exchange and a private data exchange.Alternatively, data may be tunneled between two public data exchanges orbetween two private data exchanges, or from one public exchange tomultiple private exchanges, or any other suitable combination. In someembodiments, an entity may wish to offer a publicly listed data listingon its private data exchange. For example, Entity B may wish to includeListing F of public data exchange 1100 on its own private data exchange1000. The data underlying Listing F may be tunneled from public dataexchange 1100 to private data exchange 1000. In particular embodiments,data may be tunneled between two private data exchanges. At times, afirst data provider may wish to allow a second data provider to listdata belonging to the first data provider on a private data exchange ofthe second data provider. Tunneling of data listings may allow the twodata providers to offer the same listing. As an example, Entity A andEntity B may have a business agreement to share listing F on each oftheir private data exchanges. Listing F may be the property of Entity A,but Entity B may have a license to offer it on its private data exchangeas well. In this case, both of the listings titled “Listing F” willpoint to the same data set stored in cloud computing platform 110. Thetunnel 1015 is a representation to illustrate that Listing F may beshared securely and easily between two or more data exchanges 1100 and1000. No data is copied or transferred in the tunneling. Instead, eachlisting contains a pointer to the data referenced by Listing F asdiscussed herein.

In particular embodiments, tunnel linking may be accomplished between aprivate data exchange and a public data exchange. For instance, dataexchange 1100 may be a public data exchange. Entity B may use a listinglisted on the public data exchange 1100 on its own private data exchange1000 via tunnel 1015. In some embodiments, a data listing may betunneled from one data exchange to another data exchange and then theunderlying data may be joined with another data set, and then a newlisting may be generated from the combined data set. As an example andnot by way of limitation, a first data set may be listed on a privatedata exchange that includes NBA player shooting statistics over the lastfive years. A second data set may be listed on a different data exchangethat includes weather data over the same time span. These two data setsmay be joined and listed as a new listing in either a private or apublic data exchange. Data consumers may then access this data set,subject to the viewing and access controls discussed herein, to gaininsight into how the weather might affect player shooting percentages.Additionally, if data is listed on a public data exchange (e.g., a dataexchange hosted by the cloud computing service 112), this data may betunneled to a private data exchange.

In some embodiments, tunneling of datasets may be used to create an“industry-wide” data exchange that is either public or private. Manydifferent entities may tunnel datasets to a “mega ecosystem dataexchange.” If a private ecosystem data exchange really takes off, itcould become so big and influential that it could become the standardplace for a whole industry to interchange, collaborate around, andmonetize data. There is probably room for one or two “mega ecosystemdata exchanges” in each industry. Once any one gains significanttraction, it could become the “go to” place for that industry. If morethan one viable exchange emerges in an industry, the respective hosts ofthese could decide to partner and “cross-tunnel” some (but maybe notall) assets between their exchanges to get critical mass.

While it is possible that industry coalitions could host such exchangesvia tunneling, it may be more likely that one or two large players ineach industry will bootstrap ecosystem private data exchanges fast andbroadly enough to become the defacto data exchange for their industry.This provides a significant incentive for companies that want to becomemajor players in the data side of their industries to start as soon asthey can to build their internal data exchanges and then open them upquickly to their suppliers, customers, and partners.

FIG. 12 is a diagram illustrating an example data query and deliveryservice 1200 according to some embodiments of the invention. Data queryand delivery service 1200 illustrates four ways a data provider may beable to share data. The first way is through a data exchange 900. Thedata exchange 900 may be a public data exchange or a private dataexchange. The data provider 1210 may list 1211 the data on the dataexchange according to the methods and systems described herein withreference to FIGS. 2, 4, and 8. The data consumer 1220 may access thedata in the listings by either accepting an invitation from the dataprovider as discussed herein or by requesting 1212 access to the listingas discussed herein with reference to FIG. 8. The second way data may beshared is by directly sharing the data at 1213. This may be apoint-to-point share as discussed with reference to FIG. 4, or may beany other suitable type of share, accomplished using the secure datashare methods discussed herein. Note that the data provider 1210 and thedata consumer 1220 are both users of the cloud computing service 112. Ifthe data provider 1210 wishes to share data with a non-user 1230, thisis possible as a third way to share the data, with a reader account 1215a or with a reader/writer account 1215 b. Here the non-user may need tohave a reader account but may not need to be an actual user of the cloudcomputing service 112. A reader account may allow the non-user 1230 toview the data but do nothing else to the data. Finally, a fourth way toshare data is via a file drop to cloud storage 1214. Here the dataprovider 1210 may make a copy of a data set 1216 and may allow foranother non-user 1230 to have the data set 1216. This way of sharingdata may not allow the data provider 1210 to retain control of the dataset. Thus, using the fourth way, the non-user 1230 may be able to view,manipulate, and re-share the data.

FIG. 13 is a flow diagram illustrating a method 1300 of dataexchange-based monetization according to some embodiments of theinvention. In general, the method 1300 may be performed by processinglogic that may include hardware (e.g., processing device, circuitry,dedicated logic, programmable logic, microcode, hardware of a device,integrated circuit, etc.), software (e.g., instructions run or executedon a processing device), or a combination thereof. For example, theprocessing logic may be implemented by cloud computing platform 110 ofFIG. 1. Method 1300 may begin at step 1302, where processing logicreceives a request from a user to access data of a data exchangeplatform (e.g., cloud computing platform 110 of FIG. 1). In variousembodiments, the data may be located in a public or private exchangeassociated with the platform. In another embodiment, the data may bepartially located on one or more public exchanges, and partially locatedon one or more private exchanges.

At block 1304, processing logic receives a selection indicating amonetization choice. In one embodiment, a user may be presented with oneor more options to purchase requested data. Example monetization optionsare provided below. In another embodiment, only a single monetizationoption is presented to the user. In one embodiment, a data provider ispresented with one or more monetization options, from which he or she isable to select one or more options to employ.

After receiving the selection, processing logic at block 1306 performs,by a processing device of the data exchange platform, monetizationoperations corresponding to the selection. In one embodiment, themonetization operations are performed by processing logic withoutrouting the user outside of the data exchange platform. In one example,processing logic performs different instructions corresponding to themonetization option selected. In one embodiment, processing logic mayperform the monetization operations entirely within the data exchangeplatform—e.g., without directing the user to an external paymentservice. In another embodiment, the payment operations may be performedby a third-party service, or other monetization platform associated withthe data exchange platform.

At block 1308, processing logic grants the user access to the data ofthe data exchange platform in response to successfully performing themonetization (e.g., payment) operations. As described above, a varietyof monetization options may be provided to data owners and consumers. Inone embodiment, options include a seamless transition from freemium topremium data offerings, various packages of data (e.g., collections oftables, rows, columns, functions, etc.) at various price points set bythe data owner, subscription pricing on a monthly basis per package (orother unit) of data, seamless billing via a consumer's data exchangebill, automatic (e.g., without human interaction) connection ofsubscription with data provisioning, usage-based pricing models, etc. Inother embodiments, additional options may include monetization based ona number of data queries (e.g., SQL queries) or number of results, thecomplexity and or scope of data queries and subsequent results, computepower required to determine and provide results, the value of theunderlying data, dynamic demand- or availability-based pricing (e.g.,via auctions), geolocation of consumer and requested data, a number offunction calls for secure functions, a number of matches in secure-joinfunctions, an age of resulting data, a novelty of resulting data (e.g.,does the consumer already have access to some or all of the resultingdata?), quality (e.g., accuracy) of resulting data, discovery andrecommendation of other, similar data at various prices, etc. Worthrepeating, all of the embodiments described herein may be utilized inconjunction with both public and private data exchanges and monetizationoptions may be used individually, or in combination. In one embodiment,processing logic may determine an estimated cost associated with each ofthe monetization options presented to a consumer before the query hasbeen performed. Such costs may be presented to a consumer before orafter the desired query has been provided by the consumer. In oneembodiment, trial periods and/or trial queries (e.g., up to a definedthreshold) and associated discounted or free costs may be provided toconsumers in addition to other monetization options.

Advantageously, the embodiments described herein provide for flexible,scalable, efficient monetization and authorization techniques. Byperforming all operations by a data exchange ecosystem, precise controlover access to data may be achieved, based on monetization-basedauthentication. Furthermore, as described herein, data exchange computersystems are made more efficient by the disclosed embodiments, at leastbecause such computer systems may be built, operated, and optimized toexecute all operations in concert, without relying on potentiallyinefficient or unreliable communication with an external service orplatform. Furthermore, access to particular data may be restricted basedon a monetization action or non-action (e.g., failure to pay), since acopy of the data itself is not copied outside of the data exchangeplatform. As such, data security may be increased.

FIG. 14 is a block diagram of an example computing device 1400 that mayperform one or more of the operations described herein, in accordancewith some embodiments. Computing device 1400 may be connected to othercomputing devices in a LAN, an intranet, an extranet, and/or theInternet. The computing device may operate in the capacity of a servermachine in client-server network environment or in the capacity of aclient in a peer-to-peer network environment. The computing device maybe provided by a personal computer (PC), a set-top box (STB), a server,a network router, switch or bridge, or any machine capable of executinga set of instructions (sequential or otherwise) that specify actions tobe taken by that machine. Further, while only a single computing deviceis illustrated, the term “computing device” shall also be taken toinclude any collection of computing devices that individually or jointlyexecute a set (or multiple sets) of instructions to perform the methodsdiscussed herein.

The example computing device 1400 may include a processing device (e.g.,a general purpose processor, a PLD, etc.) 1402, a main memory 1404(e.g., synchronous dynamic random access memory (DRAM), read-only memory(ROM)), a static memory 1406 (e.g., flash memory and a data storagedevice 1418), which may communicate with each other via a bus 1430.

Processing device 1402 may be provided by one or more general-purposeprocessing devices such as a microprocessor, central processing unit, orthe like. In an illustrative example, processing device 1402 maycomprise a complex instruction set computing (CISC) microprocessor,reduced instruction set computing (RISC) microprocessor, very longinstruction word (VLIW) microprocessor, or a processor implementingother instruction sets or processors implementing a combination ofinstruction sets. Processing device 1402 may also comprise one or morespecial-purpose processing devices such as an application specificintegrated circuit (ASIC), a field programmable gate array (FPGA), adigital signal processor (DSP), network processor, or the like. Theprocessing device 1402 may be configured to execute the operationsdescribed herein, in accordance with one or more aspects of the presentdisclosure, for performing the operations and steps discussed herein. Inone embodiment, processing device 1402 represents cloud computingplatform 110 of FIG. 1. In another embodiment, processing device 1402represents a processing device of a client device (e.g., client devices101-104).

Computing device 1400 may further include a network interface device1408 which may communicate with a network 1420. The computing device1400 also may include a video display unit 1410 (e.g., a liquid crystaldisplay (LCD) or a cathode ray tube (CRT)), an alphanumeric input device1412 (e.g., a keyboard), a cursor control device 1414 (e.g., a mouse)and an acoustic signal generation device 1416 (e.g., a speaker). In oneembodiment, video display unit 1410, alphanumeric input device 1412, andcursor control device 1414 may be combined into a single component ordevice (e.g., an LCD touch screen).

Data storage device 1418 may include a computer-readable storage medium1428 on which may be stored one or more sets of instructions, e.g.,instructions for carrying out the operations described herein, inaccordance with one or more aspects of the present disclosure.Monetization instructions 1426 may also reside, completely or at leastpartially, within main memory 1404 and/or within processing device 1402during execution thereof by computing device 1400, main memory 1404 andprocessing device 1402 also constituting computer-readable media. Theinstructions may further be transmitted or received over a network 1420via network interface device 1408.

While computer-readable storage medium 1428 is shown in an illustrativeexample to be a single medium, the term “computer-readable storagemedium” should be taken to include a single medium or multiple media(e.g., a centralized or distributed database and/or associated cachesand servers) that store the one or more sets of instructions. The term“computer-readable storage medium” shall also be taken to include anymedium that is capable of storing, encoding or carrying a set ofinstructions for execution by the machine and that cause the machine toperform the methods described herein. The term “computer-readablestorage medium” shall accordingly be taken to include, but not belimited to, solid-state memories, optical media and magnetic media.

Unless specifically stated otherwise, terms such as “receiving,”“determining,” “encoding,” “providing,” or the like, refer to actionsand processes performed or implemented by computing devices thatmanipulates and transforms data represented as physical (electronic)quantities within the computing device's registers and memories intoother data similarly represented as physical quantities within thecomputing device memories or registers or other such informationstorage, transmission or display devices. Also, the terms “first,”“second,” “third,” “fourth,” etc., as used herein are meant as labels todistinguish among different elements and may not necessarily have anordinal meaning according to their numerical designation.

Examples described herein also relate to an apparatus for performing theoperations described herein. This apparatus may be specially constructedfor the required purposes, or it may comprise a general purposecomputing device selectively programmed by a computer program stored inthe computing device. Such a computer program may be stored in acomputer-readable non-transitory storage medium.

The methods and illustrative examples described herein are notinherently related to any particular computer or other apparatus.Various general purpose systems may be used in accordance with theteachings described herein, or it may prove convenient to construct morespecialized apparatus to perform the required method steps. The requiredstructure for a variety of these systems will appear as set forth in thedescription above.

The above description is intended to be illustrative, and notrestrictive. Although the present disclosure has been described withreference to specific illustrative examples, it will be recognized thatthe present disclosure is not limited to the examples described. Thescope of the disclosure should be determined with reference to thefollowing claims, along with the full scope of equivalents to which theclaims are entitled.

As used herein, the singular forms “a”, “an” and “the” are intended toinclude the plural forms as well, unless the context clearly indicatesotherwise. It will be further understood that the terms “comprises”,“comprising”, “includes”, and/or “including”, when used herein, specifythe presence of stated features, integers, steps, operations, elements,and/or components, but do not preclude the presence or addition of oneor more other features, integers, steps, operations, elements,components, and/or groups thereof. Therefore, the terminology usedherein is for the purpose of describing particular embodiments only andis not intended to be limiting.

It should also be noted that in some alternative implementations, thefunctions/acts noted may occur out of the order noted in the figures.For example, two figures shown in succession may in fact be executedsubstantially concurrently or may sometimes be executed in the reverseorder, depending upon the functionality/acts involved.

Although the method operations were described in a specific order, itshould be understood that other operations may be performed in betweendescribed operations, described operations may be adjusted so that theyoccur at slightly different times or the described operations may bedistributed in a system which allows the occurrence of the processingoperations at various intervals associated with the processing.

Various units, circuits, or other components may be described or claimedas “configured to” or “configurable to” perform a task or tasks. In suchcontexts, the phrase “configured to” or “configurable to” is used toconnote structure by indicating that the units/circuits/componentsinclude structure (e.g., circuitry) that performs the task or tasksduring operation. As such, the unit/circuit/component can be said to beconfigured to perform the task, or configurable to perform the task,even when the specified unit/circuit/component is not currentlyoperational (e.g., is not on). The units/circuits/components used withthe “configured to” or “configurable to” language include hardware—forexample, circuits, memory storing program instructions executable toimplement the operation, etc. Reciting that a unit/circuit/component is“configured to” perform one or more tasks, or is “configurable to”perform one or more tasks, is expressly intended not to invoke 35 U.S.C.112, sixth paragraph, for that unit/circuit/component. Additionally,“configured to” or “configurable to” can include generic structure(e.g., generic circuitry) that is manipulated by software and/orfirmware (e.g., an FPGA or a general-purpose processor executingsoftware) to operate in a manner that is capable of performing thetask(s) at issue. “Configured to” may also include adapting amanufacturing process (e.g., a semiconductor fabrication facility) tofabricate devices (e.g., integrated circuits) that are adapted toimplement or perform one or more tasks. “Configurable to” is expresslyintended not to apply to blank media, an unprogrammed processor orunprogrammed generic computer, or an unprogrammed programmable logicdevice, programmable gate array, or other unprogrammed device, unlessaccompanied by programmed media that confers the ability to theunprogrammed device to be configured to perform the disclosedfunction(s).

The foregoing description, for the purpose of explanation, has beendescribed with reference to specific embodiments. However, theillustrative discussions above are not intended to be exhaustive or tolimit the invention to the precise forms disclosed. Many modificationsand variations are possible in view of the above teachings. Theembodiments were chosen and described in order to best explain theprinciples of the embodiments and its practical applications, to therebyenable others skilled in the art to best utilize the embodiments andvarious modifications as may be suited to the particular usecontemplated. Accordingly, the present embodiments are to be consideredas illustrative and not restrictive, and the invention is not to belimited to the details given herein, but may be modified within thescope and equivalents of the appended claims.

Any combination of one or more computer-usable or computer-readablemedia may be utilized. For example, a computer-readable medium mayinclude one or more of a portable computer diskette, a hard disk, arandom access memory (RAM) device, a read-only memory (ROM) device, anerasable programmable read-only memory (EPROM or Flash memory) device, aportable compact disc read-only memory (CDROM), an optical storagedevice, and a magnetic storage device. Computer program code forcarrying out operations of the present disclosure may be written in anycombination of one or more programming languages. Such code may becompiled from source code to computer-readable assembly language ormachine code suitable for the device or computer on which the code willbe executed.

Embodiments may also be implemented in cloud computing environments. Inthis description and the following claims, “cloud computing” may bedefined as a model for enabling ubiquitous, convenient, on-demandnetwork access to a shared pool of configurable computing resources(e.g., networks, servers, storage, applications, and services) that canbe rapidly provisioned (including via virtualization) and released withminimal management effort or service provider interaction and thenscaled accordingly. A cloud model can be composed of variouscharacteristics (e.g., on-demand self-service, broad network access,resource pooling, rapid elasticity, and measured service), servicemodels (e.g., Software as a Service (“SaaS”), Platform as a Service(“PaaS”), and Infrastructure as a Service (“IaaS”)), and deploymentmodels (e.g., private cloud, community cloud, public cloud, and hybridcloud).

The flow diagrams and block diagrams in the attached figures illustratethe architecture, functionality, and operation of possibleimplementations of systems, methods, and computer program productsaccording to various embodiments of the present disclosure. In thisregard, each block in the flow diagrams or block diagrams may representa module, segment, or portion of code, which comprises one or moreexecutable instructions for implementing the specified logicalfunction(s). It will also be noted that each block of the block diagramsor flow diagrams, and combinations of blocks in the block diagrams orflow diagrams, may be implemented by special purpose hardware-basedsystems that perform the specified functions or acts, or combinations ofspecial purpose hardware and computer instructions. These computerprogram instructions may also be stored in a computer-readable mediumthat can direct a computer or other programmable data processingapparatus to function in a particular manner, such that the instructionsstored in the computer-readable medium produce an article of manufactureincluding instruction means which implement the function/act specifiedin the flow diagram and/or block diagram block or blocks.

What is claimed is:
 1. A method comprising: receiving, from a clientdevice, a request to access data of a data exchange platform; receivinga selection corresponding to a monetization option for the data;executing, by one or more processors, a monetization operationcorresponding to the selection without directing the client deviceoutside of the data exchange platform; and granting the client deviceaccess to the data of the data exchange platform in response tosuccessfully performing the monetization operation.
 2. The method ofclaim 1, wherein the data exchange platform is a private data exchange.3. The method of claim 1, wherein the data exchange platform is a publicdata exchange.
 4. The method of claim 1, further comprising providing,in response to receiving the request, a plurality of monetizationoptions corresponding to the data.
 5. The method of claim 1, wherein themonetization selection comprises an option to transition from a freemiumto a premium account status.
 6. The method of claim 1, wherein themonetization selection corresponds to a data package comprising adefined collection of tables, rows, columns, or functions.
 7. The methodof claim 1, wherein the monetization selection corresponds to asubscription-based monetization model.
 8. The method of claim 1, whereinthe monetization selection corresponds to a usage-based monetizationmodel.
 9. The method of claim 1, wherein the monetization selectioncorresponds to a computer power for processing the data.
 10. A system,comprising: a memory to store data of a data exchange platform; and oneor more processors, operatively coupled to the memory, the one or moreprocessors to: receive, from a client device, a request to access thedata of the data exchange platform; receive a selection corresponding toa monetization option for the data; execute a monetization operationcorresponding to the selection without directing the client deviceoutside of the data exchange platform; and grant the client deviceaccess to the data of the data exchange platform in response tosuccessfully performing the monetization operation.
 11. The system ofclaim 10, wherein the data exchange platform is a private data exchange.12. The system of claim 10, wherein the data exchange platform is apublic data exchange.
 13. The system of claim 10, the processing devicefurther to provide, in response to receiving the request, a plurality ofmonetization options corresponding to the data.
 14. The system of claim10, wherein the monetization selection comprises an option to transitionfrom a freemium to a premium account status.
 15. The system of claim 10,wherein the monetization selection corresponds to a data packagecomprising a defined collection of tables, rows, columns, or functions.16. The system of claim 10, wherein the monetization selectioncorresponds to a subscription-based monetization model or a usage-basedmonetization model.
 17. The system of claim 10, wherein the monetizationselection corresponds to a computer power for processing the data.
 18. Anon-transitory computer-readable storage medium comprising instructions,which when executed, cause one or more processors to: receive, from aclient device, a request to access data of a data exchange platform;receive a selection corresponding to a monetization option for the data;execute, by the one or more processors, a monetization operationcorresponding to the selection without directing the client deviceoutside of the data exchange platform; and grant the client deviceaccess to the data of the data exchange platform in response tosuccessfully performing the monetization operation.
 19. Thenon-transitory computer-readable storage medium of claim 18, theprocessing device further to provide, in response to receiving therequest, a plurality of monetization options corresponding to the data.20. The non-transitory computer-readable storage medium of claim 18,wherein monetization selection corresponds to at least one of: a datapackage comprising a defined collection of tables, rows, columns, orfunctions; a subscription-based monetization model; or a usage-basedmonetization model.